[Refactor] IntroActivity의 Race Condition 구조 리팩토링 #410
Conversation
Summary of ChangesHello @PeraSite, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 이 풀 리퀘스트는 앱의 초기 진입점인 IntroActivity에서 네트워크 오류를 처리하는 방식을 리팩토링하여 경쟁 조건을 해결합니다. 기존 로직에서는 네트워크 연결 문제 발생 시 서버 오류 화면과 로그인 화면이 동시에 나타날 수 있는 혼란스러운 상황이 발생할 수 있었습니다. 이번 변경을 통해 초기 헬스 체크 과정에서 네트워크 오류가 감지되면, 앱은 일관되게 ServerErrorActivity로 이동하며 불필요하게 LoginActivity가 표시되는 것을 방지합니다. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
IntroActivity에서 발생하는 레이스 컨디션을 해결하기 위해 네트워크 오류 처리 방식을 리팩토링하는 PR이네요. 기존에는 NetworkErrorEventBus를 사용하여 부수 효과(side effect)에 의존하여 ServerErrorActivity로 이동했는데, 이로 인해 LoginActivity가 ServerErrorActivity 위에 표시되는 문제가 발생할 수 있었습니다. 이번 변경을 통해 IntroViewModel 내에서 명시적인 상태(ServerError)를 관리하도록 수정하여, UI 상태를 단일 진실 공급원(single source of truth)으로 만들어 코드의 안정성과 예측 가능성을 높였습니다. 전반적으로 좋은 리팩토링이라고 생각합니다. IntroActivity의 코드 간결성을 높이기 위한 작은 제안이 하나 있습니다.
| is UiState.Success -> { | ||
| startActivity<MainActivity>() | ||
| finish() | ||
| when (state.data) { | ||
| IntroState.ValidToken -> { | ||
| startActivity<MainActivity>() | ||
| finish() | ||
| } | ||
|
|
||
| IntroState.ServerError -> { | ||
| startActivity<ServerErrorActivity>() | ||
| finish() | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
UiState.Success 상태를 처리하는 블록 내에서 finish() 호출이 중복되고 있습니다. finish()를 when 표현식 밖으로 빼내어 코드를 더 간결하게 만들 수 있습니다.
is UiState.Success -> {
when (state.data) {
IntroState.ValidToken -> startActivity<MainActivity>()
IntroState.ServerError -> startActivity<ServerErrorActivity>()
}
finish()
}
Summary
ApiResultCall에서 소켓 오류, DNS 등 네트워크 오류가 발생했을 때 NetworkErrorEventBus로 이 문제를 알려줍니다.
IntroActivity가 이 NetworkErrorEventBus에 구독해 문제가 발생하면 ServerErrorActivity로 넘어갑니다.
근데 IntroViewModel의 기존 흐름인 autoLogin() 에서 명시적인 health check 결과 검증 후 흐름을 끊지 않으면 getAccessTokenUseCase()가 empty를 반환해서 LoginActivity로 넘어갑니다.
ServerErrorActivity로 갔는데도 LoginActivity가 더 늦게 이동되어서 로그인 창이 뜨는걸 방지하려고 작성했던 기존 코드를 개선합니다.
Describe your changes
Issue
To reviewers